tomcat 的并发能力分析 |
您所在的位置：网站首页 › tomcat 默认并发 › tomcat 的并发能力分析 |
tomcat 的并发能力分析
|
tomcat 参考：Tomcat的3个参数acceptCount、maxConnections、maxThreads Tomcat 的核心组件Tomcat 由 2 大核心组件组成：Connector、Container
请求在 tomcat 服务器的处理过程（BIO 模式） 客户端与服务端完成三次握手建立了连接，连接信息会存放在 ServerSocket 连接请求的队列中（队列长度为 acceptCount）如果提交到线程池的任务数没有超过 maxConnections，那么就 ServerSocket.accept() 返回 socket 对象，封装为任务提交到线程池；如果提交的任务数超过了 maxConnections，则阻塞 任务提交到线程池后，分三种情况： 线程数注： tomcat 启动后会默认占用 8080，8009和 8005 三个端口 8080 端口负责建立 HTTP 连接。在通过浏览器访问 Tomcat服务器的 Web 应用时，使用的就是这个连接器8009 端口负责和其他 HTTP服务器建立连接。在把 Tomcat 与其他 HTTP 服务器集成时就需要用到这个连接器8005 端口用来向 Tomcat 发布 shutdown 命令的对网络端口的理解实际上，电脑在网卡上的硬件网络端口只有一个。常说的 1-65535 号端口，并不是真的有这么多个硬件端口，硬件端口实际上只有一个，访问所有端口的数据包都发往这个硬件端口。硬件端口接收到数据包之后进行解析，然后通知监听对应端口的socket对象来取数据。并发量计算参考： 并发量计算 几个概念：业务并发用户数、最大并发访问数、系统用户数、同时在线用户数 假设一个 OA 系统有 1000 用户，这就是系统用户数最高峰同时有 500 人在线，是“同时在线人数”，也称作“最大业务并发用户数”500 个同时使用系统用户中20%查看系统公告，不构成压力；20%填写表格（只在提交时才会请求，填写对服务器不构成压力）；40%在发呆（什么都没做）；20%用户不停从一个页面跳转另一个页面（只有这20%对服务器产生了压力）服务器实际压力（能承受的最大并发访问数），既取决于业务并发用户数，还取决于用户的业务场景，这些可以通过对服务器日志的分析得到，一般只需要分析典型业务（用户常用，最关注的业务操作）。估算业务并发用户数的公式（测试人员一般只关心业务并发用户数） C = nL / TC^ = C + 3 × (C的平方根) C 是平均的业务并发用户数n 是 login session 的数量 L 是 login session 的平均长度T 是指考察的时间段长度 C^ 是指业务并发用户数的峰值该公式的得出是假设用户的 login session 产生符合泊松分布而估算得到。 假设：OA 系统有1000用户，每天400个用户发访问，每个登录到退出平均时间2小时，在1天时间内用户只在8小时内使用该系统。 C = 400 × 2 / 8 = 100 C^ = 100 + 3 × (100的平方根) = 100 + 3 × 10 = 130 另外，如果知道平均每个用户发出的请求数 u，则系统吞吐量可以估算为 u × C 注意： 精确估算，还要考虑用户业务操作存在一定的时间集中性（比如上班后 1 小时内是 OA 系统高峰期），采用公式计算仍然会存在偏差针对例子 OA 系统可以把 1 小时设定为考察时间的粒度，将一天 8 小时划分为 8 个区间，这样可以解决业务操作存在集中性问题，更趋于精准，偏差更小。系统吞度量要素参考：系统吞吐量（TPS）、用户并发量、性能测试概念和公式 系统吞吐量的几个重要参数：QPS（TPS）、并发数、响应时间 QPS（TPS）= 并发数 / 平均响应时间 QPS（TPS）：每秒钟request / 事务数并发数： 系统同时处理的request / 事务数响应时间： 一般取平均响应时间（很多人经常会把并发数和 TPS 理解混淆） 一个系统吞吐量通常由 QPS（TPS）、并发数两个因素决定。每套系统这两个值都有一个相对极限值，在应用场景访问压力下，只要某一项达到系统最高值，系统的吞吐量就上不去了 如果压力继续增大，系统的吞吐量反而会下降，原因是系统超负荷工作，上下文切换、内存等等其它消耗导致系统性能下降。 系统响应时间，由 CPU 运算、IO、外部系统响应等等组成。tomcat 高并发配置与优化参考：tomcat高并发配置与优化 |
【本文地址】
今日新闻 |
推荐新闻 |